1. Field of the Invention
The invention relates to a method and a network system for controlling a connection of a network node.
2. Description of the Related Art
This invention is related to mobility management, and more particularly to the support of Mobile IPv6 (Internet Protocol version 6) for SIP (Session Initiation Protocol) communications in 3GPP (Third Generation Partnership Project) networks. It actually addresses some issues that occur when a SIP communication is established via the 3GPP IMS (Internet Multimedia Subsystem), between a 3GPP node and a Mobile IP node. This invention is however not restricted to UMTS but applies to all SIP calls set up using IMS where a relation between the IP address used at the access stratum and the IP address at the SIP level needs to be established for QoS (Quality of Service) authorization purposes.
The SIP protocol supports user mobility (i.e. users changing their point of attachment and therefore getting a new IP address) by means of re-registration and/or re-INVITE and by providing the new IP address in the SDP SIP body part. SIP thus has a built-in support for mobility, but there are several reasons why Mobile IP mobility can be preferred to SIP mobility by the user:
For example, SIP Mobility would not allow a service continuity for streams over TCP. In fact, since the IP address is changed, the TCP session needs to be closed down and a new one established (this takes some time and implies delay). In addition, handling the mobility at the SIP level is application specific and therefore several mobility procedures may need to occur (e.g. considering a UDP stream protected by IPsec (Internet Protocol Security), after the SIP mobility procedure is executed to update the other party with the new IP address; the IPsec SA (Security Association) needs also to be updated with the new IP address: this requires additional messages and implies delay in the procedure) whereas Mobile IP handles mobility transparently to all applications and only one procedure is required.
The following describes the interaction issues between Mobile IP and the 3GPP IMS. When a 3GPP UE establishes a communication via the 3GPP IMS, as described in 3GPP TS 29.207, the GGSN (Gateway GPRS Support Node) verifies with the PDF (Policy Decision Function) (through the Go interface) that the requested communication is valid.
If the request is valid, (i.e. the communication is authorized), as part of this procedure, the PDF also installs some packets filters in the GGSN.
The packet classifier parameters are:                The Source IP address;        The Destination IP address;        The Source ports;        The Destination ports;        And the Protocol ID.        
These parameters are set by the PDF based from the information in the SDP fields of the SIP signaling, between the 3GPP node and the P-CSCF server. Uplink and downlink packets not matching the packet filters are dropped.
Considering Mobile IP, the following issues arise:
In the following, a scenario illustrated in FIG. 1 is considered where Node B is a Mobile IP node and first has a Care of address (CoA1). A Care-of Address is a unicast routable address associated with a mobile node while visiting a foreign link. This address may change, in contrast to the Home Address (HoA) of the mobile node which is fixed.
The GGSN is connected to a SIP server of an IMS (IP Multimedia Subsystem) over the Go interface. Furthermore, a connection to a node A, which is a 3GPP node, is established via a SGSN (Serving GPRS Support Node) and a radio path via a Base Station and the like, which is not shown in detail.
According to the procedure specified in 3GPP TS 29.207,                the source IP address of the downlink-direction (from the GGSN to node A) packet filters will be set to CoA1        the destination IP address of the uplink-direction (from node A to GGSN) packet filters will be set to CoA1        
It is now assumed that Node B changes its IP address to CoA2 and sends a Binding Update message to inform Node A (as specified, for example, in “Mobility Support in IPv6”, Internet draft by Johnson, Perkins, Arkko of June 2003, http://www.ietf.org/internet-drafts /draft-ietf-mobileip-ipv6-24.txt):                Packets sent from Node A to Node B will then have the destination IP address field set to the CoA2        Packets sent from Node B to Node A will have the source IP address field set to CoA2        Neither uplink nor downlink packets will therefore match the packet filters and will typically be dropped at the GGSN.        
It has to be noted that many other problems exist when a Mobile IP node is communicating with a 3GPP node: e.g. the so-called Return Routability (RR) test specified in the Mobile IPv6 specifications (as defined in the above document, for example) will be dropped since the CoTI (Care-of Test Init) message will be sent from the new CoA, and will therefore not match the packets filters installed in the GGSN. The present application, however, does not address the problem of the RR test in 3GPP but assumes that the Mobile IP node can authenticate binding update message using other methods (e.g. signing the Mobile IP binding update thanks to asymmetric technologies). The present application focuses on the problem described in the above paragraphs.
In addition, the problem extends to the more general scenario where the UE sets up a communication with a correspondent node (CN) that is a Mobile IP node. With respect to the scenario shown in FIG. 1, in this case the node A would set up a communication with the node B.
When the UE activates the PDP context and provides TFTs (Traffic Flow Templates) for QoS, the source IP address of packets destined to the UE can be used as filtering information to allow the GGSN to apply the appropriate treatment to the packets (e.g. QoS). However, if the CN changes its address (e.g. from HoA to CoA or from old CoA to new CoA), the GGSN would not be able to filter the packets appropriately.
The issues described above were due to the fact that the CN is mobile, but some other issues also exist when the UE is mobile. These issues are described below.
3GPP is already considering introducing Mobile IP for support of mobility from GPRS to alternative accesses (e.g. WLAN). However, the current mechanisms of 3GPP, and more particularly the Authorization Request/Authorization Decision procedure, defined in TS 29.207, would not support Mobile IP. In order to support Mobile IPv6 in current 3GPP networks (at least as a basic solution) the mobile UE (i.e., the mobile node which changes its address) needs to have a Home Address (HoA) registered with a Home Agent, and obtains the Care-of Address (CoA) from the GGSN upon PDP context activation. Mobile IPv6 signalling and mechanisms are therefore transparent to PDP context management.
In order for the mobile UE to allow mobility management using Mobile IP and to avoid SIP mobility, the mobile UE needs to provide the Home Address (HoA) as the address provided in the SDP body (as described in TS 24.228 when the user establishes the media stream with SIP). The use of the care-of address would in fact require SIP mobility since if the UE changes the CoA, the UE needs to re-register with the SIP server or modify the on-going communication appropriately in order to maintain reachability. However, the use of the HoA in the SIP messages does not allow the QoS authorization through the Go interface to work correctly.
This is described in the following by referring to a signal flow diagram shown in FIG. 2, illustrating an example of GPRS and COPS interactions during a (mobile originating) session setup when SBLP (Service-based Local Policy) is applied. This flow diagram is described in detail in 3GPP TS 24.228 V5.5.0, for example. In the following, a short summary of the messages is given.
In process 1, the UE initiates a session by sending a SIP INVITE request to the P-CSCF. The P-CSCF replies with a 100 Trying message in order to inform the UE that the session initiation is carried out. The P-CSCF forwards the SIP INVITE request in process 3 to the CN (i.e., the corresponding network elements for the CN). IN response to the INVITE request, first a 100 Trying message is sent to the P-CSCF, after this, a 183 Session Progress response is sent in process 5.
In process 6 (Authorise QoS Resources), the P-CSCF obtains a Meida Authorisation Token from the PDF at the reception of the 183 Session Progress response at the P-CSCF. The 183 Session Progress response sent in process 7 from the P-CSCF to the UE typically contains the P-Media Authorization header, which holds the Media Authorisation Token. Upon receipt of the Media Authorisation Token, the UE generates a flow identifier which identifies an IP media flow associated with the SIP session. The Flow Identifiers are based on the sequence of media flows in the SDP. A Flow Identifier combined with the Authorization Token is sufficient to uniquely identify an IP media flow.
In processes 8 to 11, the UE responds with a PRACK, in response to which a 200 OK (PRACK) message is sent from the CN to the UE.
In process 12 (GPRS: Active PDP Context), the UE sends an Activate PDP Context message to the SGSN as defined in 3GPP TS 24.008. The UE associates the PDP context to the session by including the media authorisation token information and the flow identifier(s) information. The PDP context is bi-directional.
In process 13 (GPRS: Create PDP Context) sent from the SGSN to the GGSN, the SGSN checks the user profile to authorise the requested QoS and also the available resource, if both are granted, it sends the corresponding Create PDP Context message to the GGSN as defined in 3GPP TS 29.060. This message contains the media authorisation token information and the flow identifier(s) information.
When the Create PDP Context message is received in the GGSN containing the media authorisation token information and the flow identifier(s) information, the Policy Enforcement Point in the GGSN sends a COPS REQ message in process 14 to the PDF as described in 3GPP TS 29.207. The PDF verifies that the media authorisation token information and the associated flow identifier(s) information are as expected.
After this, the PDF sends a COPS DEC message back to the GGSN in process 15,. The GGSN sends a COPS RPT message back to the PDF in process 16, and includes an acknowledgement and/or an error response to the DEC message.
Thereafter, the GGSN checks its own available resources and if enough resources are available, it sends a Create PDP Context Response message in process 17 back to SGSN containing the negotiated value of the UMTS QoS IE as defined in 3GPP TS 29.060. In process 18 (GPRS: Active PDP Context Accept), the SGSN sends an Activate PDP Context Accept message to UE containing the negotiated value of the UMTS QoS Information Element as defined in TS 24.008.
As the confirmation of the preconditions are requested in the 183 (Session Progress) response, when the UE finishes the QoS reservation for both the uplink and downlink direction, according to the GPRS procedures as indicated by the GPRS: Active PDP Context Accept message, it sends an UPDATE or COMET request in processes 19 and 20 to the terminating endpoint (i.e., the CN), via the signalling path established by the INVITE request. The UPDATE request includes in the SDP the information about the successful QoS bi-directional mode, due to the successful bi-directional PDP context established. The SDP indicates that the QoS resource reservation for both send and receive mode was successful from the terminating endpoint side.
This process is followed by a 200 OK (COMET) responses in processes 21 and 22, and by 180 Rining messages in process 23 and 24. In processes 25 to 28 the UE sends again a PRACk message to the CN, which is replied to by a 200 OK (PRACK) message 9.
When the P-CSCF receives the 200 (OK) response to the INVITE request in process 29, the PDF sends a COPS DEC message to the GGSN in process 30 to enable the use of the authorised QoS resources, i.e. to open the ‘gate’, and allow packet flow in both directions in accordance with the policy decision within the GGSN Policy Enforcement Point.
The GGSN receives the COPS DEC message (process 30) and enables the use of the authorised QoS resources, i.e. opens the ‘gate’ within the GGSN, and sends a COPS RPT message back to the PDF in process 31.
In process 32, the 2000K (INVITE) message is forwarded to the UE, which finally responds with an ACK message in process 33 and 34.
In the following, the messages important for understanding the present application are summarized.
In message 12 , the UE sends the Activate PDP (Policy Decision Function) context activation message including the Binding information. This binding information will be used by the PDF to determine the authorised QoS, packet filters, and gate status to be applied (message 14). As described in 3GPP TS 29.207, the PDF (located in the P-CSCF) more particularly verifies that the binding information provided by the GGSN is associated with an ongoing SIP session at application layer.
If such is the case, the PDF then responds with a Authorization_Decision message (message 15) containing Packet filters. And as specified in 3GPP TS 29.207 “the GGSN shall enforce the policy decision”. “To enforce the policy decision, the GGSN shall install the packet filters received from the PDF, and ignore the UE supplied TFT.” As mentioned above, the packet classifier parameters are: the Source IP address, the Destination IP address, the Source ports, the Destination ports, and the Protocol ID.
Two issues can be identified:
First, as stated in the 3GPP TS 29.207, “in the uplink direction, IP packets which do not match any packet filter shall be silently discarded”. Since the SIP session was established based on the UE's HoA, the Source IP address of the uplink packet filter received from the PDF will point to the UE's HoA. However, packets sent by the UE have their source address set to the PDP address which is also the Care of Address. The uplink packets will therefore be dropped by the packet filters.
Another issue is also related to the downlink packets: since the SIP session is established between the UE (which is in this case the mobile node MN) and the CN (correspondent node, i.e., the network node with which the UE establishes a SIP session), the source IP address of the packet filters will be set to the CN's IP address whereas, the packets may be coming from the UE's Home agent (i.e. due to tunnelling by the Home Agent as in Mobile IP procedures). The fields not matching, the downlink packets will be dropped.
In conclusion, Mobile IP would not be supported by GPRS.
This is also a problem with respect to security and mobility. Namely, current firewalls do not support the Mobile IP protocol, but many issues exist preventing Mobile IP communications between a node protected by a firewall and an external node.
In detail, in order to protect the UEs from different types of Denial of Service (DoS) attacks, mobile operators will deploy firewalls in the networks. The following paragraph provides some background information on stateful firewall:
When a trusted internal host connects to a TCP socket on another host, a so-called stateful packet inspection filter protecting the network creates a state: upon receiving the SYN packet, the firewall makes an entry in its state table containing the destination socket and the response socket, and then forwards the packet to the destination. When the response comes back, the filter can simply look up the packet's source and destination sockets in its state table, see that they match an expected response and pass the packet. If no table entry exists, the packet is dropped because it was not requested from inside the network. The filter removes state table entries when the TCP close session negotiation packets are routed through, or after some time of inactivity based on a timer (usually a few minutes). This ensures that dropped connections don't leave table “holes” open.
Stateful packet inspection filters similarly create a state for UDP datagrams and after time of inactivity based on a timer (usually a few minutes), the states are removed.
Considering Mobile IP, an inner Mobile Node (MN) (i.e., a MN protected by a firewall) may send a first packet to its Home Agent (HA) (located outside the firewall) such as a Binding update (BU) message. According to current technology, this will create an entry in the stateful firewall allowing packets sent from the HA to the MN to pass the firewall. Such state will however only be based on timer, and it will typically expire after some time of inactivity. After being idle for some time, a packet may however be sent to the MN and the firewall not having the state for this node will discard the packet.
Other issues also exist when e.g. an external node (i.e., located outside the firewall) is a Mobile IP node and changes its CoA:
In scenarios where the external node is an IP mobile node and it either decides to use route optimization, or was already doing so and changes its CoA (similar as described above), all the packets sent from the external mobile node with the new CoA do not match the state in the filter and are therefore dropped. This happens because either the state in the firewall was based on the external node's HoA or on the old external node's CoA.
Hence, similar problems as described above with respect to packet filtering also occur upon using firewalls.